BG-834: Recurrent cascade by ndiezel0 · Pull Request #200 · valitydev/hellgate

ndiezel0 · 2026-03-19T21:59:54Z

No description provided.

WWWcool

Не понял в какой момент происходит добавление реккурентного токена к карте/кастумеру - это по идее на получение от провайдера должно работать, но кода нет. Тестов мало, нужен тесты на каскад и подтверждением работы

apps/hellgate/include/hg_invoice_payment.hrl

apps/hellgate/test/hg_direct_recurrent_tests_SUITE.erl

WWWcool · 2026-03-20T08:21:24Z

apps/hellgate/test/hg_direct_recurrent_tests_SUITE.erl

+    CustomerID = <<"test-customer-42">>,
+    RecurrentParent = ?recurrent_parent(Invoice1ID, Payment1ID),
+    BaseParams = make_recurrent_payment_params(true, RecurrentParent, ?pmt_sys(<<"visa-ref">>)),
+    Payment2Params = BaseParams#payproc_InvoicePaymentParams{customer_id = CustomerID},


а если не передать парент реккурент - сохранится?

Добавил тест. Сохранится.

apps/hellgate/test/hg_direct_recurrent_tests_SUITE.erl

CLAUDE.md

WWWcool · 2026-03-20T08:24:23Z

rebar.config

    {genlib, {git, "https://github.com/valitydev/genlib.git", {tag, "v1.1.0"}}},
    {woody, {git, "https://github.com/valitydev/woody_erlang.git", {tag, "v1.1.1"}}},
-    {damsel, {git, "https://github.com/valitydev/damsel.git", {tag, "v2.2.27"}}},
+    {damsel, {git, "https://github.com/valitydev/damsel.git", {branch, "BG-834/customer_payment"}}},


не забыть

apps/hellgate/src/hg_invoice_payment.erl

WWWcool · 2026-03-20T14:55:18Z

apps/hellgate/src/hg_customer_client.erl

+    {ok, Customer} = call(customer_management, 'Create', {#customer_CustomerParams{party_ref = PartyConfigRef}}),
+    Customer.


ключа идемпотентности нет, в параметрах создания нет привязки, значит если что то пойдет не так - у тебя будет миллиард пустых кастумеров

Например создание и сразу привязка к платежу? А если платеж не успешен? Я думал чтобы список платежей в кастомере был списком успешных платежей

это все верно, но после создания может же быть проблема - а можно делать чтобы у тебя в случае если не было кастумера и нужно создать ты мог в рамках транзакции создать, добавить карту и добавить реккурент - при этом проверяя не было ли уже их - чтобы не было дублей?

Карты и токены добавляются идемпотентно, в этом плане проблем нет

Идемпотентностью создания самого кастомера (это будет происходить в капи) займется бендер на основе ExternalID

WWWcool · 2026-03-20T15:00:34Z

apps/hellgate/src/hg_invoice_payment.erl

+    #customer_RecurrentToken{
+        id = <<"parent">>,
+        provider_ref = ProviderRef,
+        terminal_ref = TerminalRef,
+        token = RecToken,
+        created_at = CreatedAt,
+        status = {active, #customer_RecurrentTokenActive{}}
+    }.


звучит странно - ты его делаешь, но в кубасити его нет, кто то кро прочитает события пойдет спрашивать что то по ним, а там ничего

то есть сама идея что нужно учесть родительский вроде ок

Поправлено

WWWcool · 2026-03-20T15:08:24Z

apps/hellgate/src/hg_invoice_payment.erl

+        payment = #domain_InvoicePayment{
+            id = PaymentID,
+            make_recurrent = true,
+            customer_id = CustomerID,


а если кастумера не было мб создать?

Это будет происходить на уровне капи

но у тебя же есть проверка - when CustomerID =/= undefined - то есть ты предполагаешь что такой вариант возможен - а я как раз на него и пишу - что не создать ли в таком случае?

Это sanity check проверка. Могут быть сценарии в который мы не хотим ассоциировать платеж с кастомером, потому он не передается. Например этот функционал кому-то конкретно не нужен. Тогда для него создаваться не будет. Но пусть это решает бордер, а не сам ХГ.

так это вопрос тогда к логике - кто управляет созданием - только фронт дает сигнал или мы сами создаем - у меня было ощущение что нам нужно агрегаты эти заводить в любом случае, а если сверху кто то спросил - условно есть ли у этого реккурента ассоциированный кастумер - отдать готового

WWWcool · 2026-03-20T15:10:02Z

apps/hellgate/src/hg_invoice_payment.erl

+                T;
+            error ->
+                %% Cascade route without pre-existing token — use parent's token
+                get_recurrent_token(get_payment_state(InvoiceID, PaymentID))


а если это токен другого провайдера?

Убрал этот кейс. Его не может быть.

apps/hellgate/test/hg_direct_recurrent_tests_SUITE.erl

WWWcool · 2026-03-20T17:37:11Z

apps/hellgate/src/hg_customer_client.erl

+    {ok, Customer} = call(customer_management, 'Create', {#customer_CustomerParams{party_ref = PartyConfigRef}}),
+    Customer.


это все верно, но после создания может же быть проблема - а можно делать чтобы у тебя в случае если не было кастумера и нужно создать ты мог в рамках транзакции создать, добавить карту и добавить реккурент - при этом проверяя не было ли уже их - чтобы не было дублей?

WWWcool · 2026-03-20T17:38:04Z

apps/hellgate/src/hg_invoice_payment.erl

+                CID =/= undefined
+            ->
+                case hg_customer_client:get_recurrent_tokens(InvID, PmtID) of
+                    [_ | _] = Tokens -> [?cascade_tokens_loaded(Tokens)];


а есть же length для длинны массива

WWWcool · 2026-03-20T17:39:38Z

apps/hellgate/src/hg_invoice_payment.erl

-                ParentToken = make_parent_recurrent_token(ParentSt),
-                AllTokens = [ParentToken | CubastyTokens],
-                [?cascade_tokens_loaded(AllTokens)];
+        case {InheritedCustomerID, PayerParams} of


что то метание вышло - то есть если у нас есть реккурент родительский, но его еще нет в кубасити, то мы его никак не обрабатываем? а почему прогрев базы не делать таким образом?

Потому что тогда нам надо прогревать еще и всех детей родителя (сколько их?). Я не уверен что этим стоит заниматься посреди проведения платежа

WWWcool · 2026-03-20T17:40:41Z

apps/hellgate/src/hg_invoice_payment.erl

+    case (get_payment(ParentPayment))#domain_InvoicePayment.customer_id of
+        CustomerID -> CustomerID;
+        undefined -> CustomerID;
+        _Other -> throw(#payproc_InvalidRecurrentParentPayment{details = <<"Customer ID mismatch with parent">>})


я так и не понял пока нафиг этот кастумер передается сверху, если ты его можешь определять по родительскому платежу?

Чем отличается родительский платеж от неродительского? И там и там мы можем передать CustomerID, InvoicePaymentParams один и тот же.

WWWcool · 2026-03-20T17:42:41Z

apps/hellgate/src/hg_invoice_payment.erl

+        payment = #domain_InvoicePayment{
+            id = PaymentID,
+            make_recurrent = true,
+            customer_id = CustomerID,


но у тебя же есть проверка - when CustomerID =/= undefined - то есть ты предполагаешь что такой вариант возможен - а я как раз на него и пишу - что не создать ли в таком случае?

BG-834: Recurrent cascade

057c29d

ndiezel0 requested a review from WWWcool March 19, 2026 21:59

Merge branch 'master' into BG-834/customers

8b81aa7

WWWcool reviewed Mar 20, 2026

View reviewed changes

Fixes

e871a93

WWWcool reviewed Mar 20, 2026

View reviewed changes

ndiezel0 added 3 commits March 20, 2026 19:47

Fixes

c0d2fd0

Fix

04f5e64

Fix

4b3bc8a

WWWcool reviewed Mar 20, 2026

View reviewed changes

		{ok, Customer} = call(customer_management, 'Create', {#customer_CustomerParams{party_ref = PartyConfigRef}}),
		Customer.

Conversation

ndiezel0 commented Mar 19, 2026

Uh oh!

WWWcool left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants